FunnelFlux Pro имеет ряд ресурсов, которые являются необходимыми предпосылками для создания воронки и запуска полнофункциональной кампании.
Это:
- Источники трафика
- Источники офферов
- Офферы
- Лендинги
- Собственный домен (не совсем ресурс, но необходим)
Ниже приведена разбивка конфигурации этих элементов и их влияние на процессы отслеживания.
Источники трафика
Источник трафика определяет источник входящих посетителей, и его необходимо выбрать при создании URL-адресов кампании.
Конфигурация источника трафика имеет два основных компонента:
- Поля отслеживания URL
- Отслеживание конверсий
Конфигурация полей отслеживания URL
Смотрите изображение ниже:
FunnelFlux позволяет использовать 20 пользовательских полей отслеживания, каждое из которых должно иметь имя (псевдоним) и необязательное значение-заполнитель. Числа слева представляют номера столбцов в базе данных. Таким образом, эта конфигурация создает псевдонимы для отображения имени -> ID столбца.
Конфигурация полей отслеживания используется при создании ссылок перенаправления/прямых ссылок -- эти поля определяют данные строки запроса, специфичные для источника трафика, добавляемые к URL.
У нас есть два зарезервированных поля, которые нельзя удалить, но можно переименовать -- campaign и external.
Они зарезервированы для значений ID кампании (или названия кампании) и ID отслеживания кликов соответственно.
Заполнители должны быть токенами/макросами, которые будет анализировать источник трафика (поскольку они находятся в URL, которые предполагается использовать в источнике трафика), а токен FunnelFlux - это формат токена, который можно использовать в URL лендингов/офферов для передачи данных источника трафика дальше.
Полезные заметки
- Источники трафика не обязательно должны быть рекламными платформами -- вы можете создать источник трафика для электронных писем, используя теги слияния электронной почты в качестве токенов. Вы также можете создавать источники трафика для конкретных партнеров, с ручными полями и позволить пользователю передавать статические данные. При этом рекомендуется установить заполнитель как REPLACE, чтобы уменьшить вероятность человеческой ошибки при использовании ссылок.
- Если заполнитель поля отслеживания оставлен пустым, мы исключим его из сгенерированного URL, но поле все равно будет захвачено, если данные URL существуют.
- В некоторых случаях может иметь смысл разблокировать наши зарезервированные поля и переименовать их, когда ID кампании или клика автоматически добавляется к URL -- например, когда Facebook автоматически добавляет "FBCLID". В нашем шаблоне внешнее поле переименовано в FBCLID и ему задан пустой заполнитель. Таким образом, наша система НЕ будет добавлять FBCLID= к сгенерированным URL, но будет захватывать входящие значения параметра строки запроса FBCLID и сохранять их как внешние ID кликов.
- Пользователи могут в любое время переименовывать поля, и это может привести к тому, что данные, записываемые в пронумерованный столбец, внезапно изменятся в какой-то момент времени, поэтому следует проявлять осторожность, чтобы не существенно изменять данные, поступающие в каждый пронумерованный столбец после настройки. Скорее, было бы лучше архивировать этот пронумерованный ряд и создать новое поле или использовать новый источник трафика.
- Архивированные поля отслеживания скрыты из вида и выпадающих списков отчетов, но все еще отображаются в данных. Создание новой строки с тем же именем, что и у архивированного поля, разархивирует это поле, а не создаст дубликат поля, поскольку архивированное поле все еще будет захватывать и хранить данные, если URL используют его.
- При переименовании полей сохраняется значение previousName для сопоставления старых данных URL ссылки с переименованными значениями.
Конфигурация отслеживания конверсий
Здесь пользователи могут установить метод передачи данных о конверсиях обратно в источник трафика.
URL постбэков - это простые GET-запросы к источнику, передающие любые необходимые данные и наш токен {external} для доступного ID клика.
HTML позволяет использовать JS или пиксели изображений. Чтобы это работало, пользователи должны отслеживать конверсию с помощью нашего JavaScript-отслеживания, которое передаст HTML-код на страницу, если он установлен.
Пользовательские сценарии - это специальные интеграции, которые мы создали для различных источников трафика, обычно они включают API.
Пользователям необходимо обратиться к нашей справочной документации для получения подробностей о настройке. Их следует использовать, если они доступны, так как они обеспечивают гораздо более надежное отслеживание. Все они основаны на взаимодействии сервер-сервер, поэтому работают, когда конверсии передаются в FunnelFlux с помощью URL постбэков, а также если конверсии запускаются с помощью JS.
Источники офферов
Они определяют источник офферов, которыми обычно являются партнерские сети. Хотя пользователь вполне может создавать источники, такие как "Мои продукты" или название веб-сайта.
Они служат трем целям:
- Шаблонизация передачи данных, так как когда оффер использует этот источник, он наследует конфигурацию передачи данных
- Шаблонизация URL постбэков, чтобы пользователям было легко копировать/вставлять URL в сети
- В качестве общей категории для отчетности
Примечание: мы намерены обновить нашу парадигму передачи данных в ближайшем будущем. Сейчас конфигурация источника оффера наследуется в одном направлении в момент его выбора в конфигурации оффера. Если пользователь обновляет источник оффера, никаких изменений в офферах не происходит. В будущем мы создадим строгое наследование, при котором офферы сначала наследуют конфигурацию передачи данных из источника (и некоторые другие конфигурации), затем на уровне оффера могут быть установлены дополнительные поля, а также переопределения.
Передача данных
Здесь пользователи могут использовать форменный подход для создания строки запроса, добавляемой к базовому URL страницы в общих настройках.
Этот подход уменьшает вероятность человеческой ошибки и позволяет нам лучше шаблонизировать передачу данных.
В качестве лучшей практики базовый URL страницы должен содержать все статические данные URL, которые никогда не изменятся. Для партнерских URL это часто означает включение некоторого ID партнера/оффера.
В идеале все динамические данные должны быть настроены через раздел передачи данных.
Полезные заметки
- Некоторые имена полей ограничены, например vid, n, c, ts и т.д., которые используются для зарезервированных параметров, передаваемых FunnelFlux или нашим Javascript
- Чтобы передать данные URL, вы можете выбрать этот вариант, а затем ввести только имя ключа строки запроса. При сохранении элемент свернется до
{data-url_key_name}-- мы намерены улучшить это позже. - Обратите внимание, что данные, переданные в ссылках отслеживания, доступны через этот токен, как и данные строки запроса, переданные в наш буфер URL. То есть, любые данные строки запроса URL, переданные в ссылку перенаправления или действия, которые НЕ являются определенным полем отслеживания, все равно будут сохранены в данных сессии и могут быть доступны с помощью
{data-url_key_name}. Однако они не будут доступны в отчетности. - Для передачи составных или других данных выберите пользовательскую строку. Здесь вы можете использовать токены как обычно, например,
{funnel-id}-{campaign}-{trafficsource-id}. Если вы передаете сложные данные, такие как строка URL, ее не нужно кодировать, так как наша система автоматически кодирует URL при сохранении.
Отслеживание конверсий
Этот раздел довольно понятен.
Для шаблонизации URL постбэка введите токены дохода/необязательного ID транзакции, которые будет анализировать и заменять платформа источника оффера.
Для ID хита проверьте поле, в которое вы передаете наше значение {hit} при передаче данных. Если это, например, "aff_sub5", то на странице отслеживания конверсий вы должны ввести соответствующий токен источника оффера, который будет представлять сохраненное значение aff_sub5, например, {aff_sub5}
Полезные заметки
- Конверсии, переданные в FunnelFlux с идентичными значениями ID хита и TxID, в настоящее время заменят существующую конверсию, но не вызовут дублирования. Сейчас это обновляет временную метку конверсии. Мы намерены заменить эту функциональность, чтобы НЕ обновлять исходную временную метку, так что новое событие, если это дубликат, фактически игнорируется.
- В настоящее время отслеживание конверсий не дедуплицируется в отношении отправки событий в источник трафика. Таким образом, даже если FunnelFlux дедуплицирует конверсию внутренне, событие все равно отправляется в источник трафика. Мы также намерены обновить это поведение, чтобы не отправлять дублирующиеся события.
- Таким образом, если пользователи хотят запустить несколько законных конверсий, они всегда должны указывать уникальные значения ID транзакции через параметр "tx" в нашем URL постбэка/JS.
Офферы
Офферы должны выбрать источник оффера, чтобы сначала унаследовать важную конфигурацию, экономя время и уменьшая вероятность человеческой ошибки.
Затем оффер имеет базовый URL, который должен включать все статические данные, а все динамические данные передаются через раздел передачи данных.
Когда FunnelFlux перенаправляет на оффер, он перенаправляет на базовый URL + конфигурация передачи данных = конечный URL оффера.
Категории офферов предназначены исключительно для группировки в отчетности и не оказывают функционального влияния.
Ссылки на действия страницы
Это URL-адреса действий (CTA), которые будут использоваться на страницах. Они имеют общий формат:
https://DOMAIN/action/number
В FunnelFlux URL-адреса переходов (ссылки действий) на страницах не указывают место назначения. Они ссылаются на "действие" для выполнения. В момент клика FunnelFlux обрабатывает конфигурацию воронки для текущего пользователя и, основываясь на его текущей известной позиции узла, выполняет действие X из этого узла.
Таким образом, FunnelFlux не прогнозирует, каким будет следующее назначение для пользователя, и поэтому невозможно создать ссылку на странице, которая создает переход/действие, но также принудительно перенаправляет на определенный узел.
Конечно, можно использовать узел условия и направлять на основе некоторых данных URL, переданных в URL действия, но это отдельная функциональность -- действие с лендинга все равно будет естественно переходить к следующему ожидаемому узлу (в данном случае условию).
Обратите внимание, что ссылки действий являются общими и не должны быть специфичными для страницы, воронки или источника. В конструкторе воронок эти действия также можно получить с добавленными параметрами по умолчанию. Это будет обсуждаться в техническом документе по воронкам.
ID продуктов интеграции
Это раздел в бета-версии - он специально предназначен для интеграций веб-хуков, которые мы планируем создать, где они будут передавать ID продуктов и ID посетителя. Если у оффера установлены ID продуктов, мы сможем перекрестно сопоставить, чтобы определить, что X ID продукта должен быть Y оффером --> это оффер, который конвертировался. В настоящее время имеет ограниченное применение.
Лендинги
Как и офферы, лендинг - это просто страница.
Основные отличия, помимо значка/имени, заключаются в том, что у лендинга нет "источника", из которого он наследует конфигурацию
Лендинги следует использовать для любой страницы, которая не будет напрямую создавать доход от действий пользователя на этой странице или вытекающих из нее.
Например, страница оформления заказа, вероятно, будет страницей оффера -- но предыдущая страница продажи товара будет лендингом, так как страница оформления заказа - это место, где пользователь в конечном итоге конвертируется.
Любая страница, которая является конечной точкой, где посетитель перенаправляется на какую-то стороннюю страницу, например, партнерскую сеть, обязательно будет оффером, а не лендингом.
Обратите внимание, что хотя лендинги не конвертируют, в отчетности они все равно наследуют доход и конверсии, созданные пользователями позже в их пути.